Linux 安装的本质：三层结构与两条原则
Linux 桌面被搞坏，绝大多数时候不是不稳定，而是在错误的层用了错误的工具。三层结构，两条原则：Flatpak 管应用，官方源管系统。
同一个软件，有时 apt install，有时下载 .deb 包，有时用 Flatpak，有时还有 Snap 和 AppImage。选错了，轻则桌面找不到图标，重则依赖冲突拖垮整个系统。
网上教程各执一词——有人说永远用 apt，有人说 Flatpak 才是未来，有人推荐加第三方 PPA。跟着做了，系统却在一次 apt upgrade 后崩掉。我花了很久才想明白：这些方案不是互相替代的关系，而是作用于三个完全独立的系统层，而大多数教程从来不告诉你这一点。
三个独立的系统
Windows 和 macOS 里，安装是一个完整动作——安装程序带着依赖、注册信息、桌面图标一起到位。Linux 不是这样。一个软件能不能跑、能不能被桌面识别、会不会拖垮其他软件，分别由三个独立系统决定。
可以把 Linux 想象成一栋大楼：水电、电梯、门禁各自独立运作，住户只关心能不能住，但出了问题必须分清是哪一层出了故障。对应到软件：依赖层管能不能跑（共享库版本），运行层管怎么隔离（沙箱机制），桌面集成层管在不在菜单里（.desktop 文件注册）。
三层逻辑上各自独立，但工程上有桥接——Flatpak 会自动注册 .desktop 文件，apt 安装也会处理桌面集成。模型用来理解结构，排错时要注意工具可能跨层作用。
从共享到隔离
传统 Linux 软件建立在共享依赖模型上。APT、DNF 维护的是一个全局依赖图——所有软件共享同一套底层库，比如 glibc、GTK、Qt。好处是高效，每个应用不用自带一整套运行环境；代价是强耦合，改一处牵动全局。
.deb 和 .rpm 包在这种模型下不是独立应用，而是系统环境的一部分——装一个包就是往全局依赖图里插入一个节点，它的版本要求直接影响其他节点。装了 A 要求 glibc 2.35，装了 B 要求 glibc 2.31，二者互斥，这就是依赖地狱。
Flatpak 和 Snap 在运行层做了隔离——每个应用携带自己的运行环境，沙箱执行，不再依赖系统共享库。依赖从共享变为自包含，应用和系统从强耦合变为弱依赖。AppImage 更极端：一个文件就是整个应用，不需要安装，默认不参与系统注册。
到这里你会发现一个关键点——Flatpak 解决了依赖冲突，但解决不了"桌面找不到图标"的问题。那属于第三层。
桌面环境（GNOME、KDE）并不直接识别已安装的软件。它们依赖 .desktop 文件——应用的元数据名片，记录启动路径、图标、名称、分类。一个应用是否"可见"，取决于这张名片有没有正确生成并放在正确目录，和软件安装成功与否无关。AppImage 和手动安装通常不处理这一层，所以经常出现"装了但找不到"的情况。
问题定位速查
理解三层结构后，各种疑难杂症都有了解释。依赖版本过低报错——第一层版本约束不满足。Flatpak 版本的软件打不开文件——不是软件坏了，是运行层沙箱默认限制了文件系统权限。软件不显示在菜单——第三层没注册 .desktop 元数据。自启动失败——第三层启动项缺失。
最反直觉的案例：同一个软件，用 apt 装了能正常访问文件，换成 Flatpak 版本却不行。问题不在软件本身，而在运行层的权限隔离。
两条原则
理解三层结构之后，工具选择不再是看心情。
普通桌面应用，一律用 Flatpak。 Obsidian、Spotify、Telegram、VS Code、GIMP——这类应用不需要深度系统集成。Flatpak 的运行层隔离意味着应用自带依赖、不碰系统共享库，出了问题删掉重装，系统纹丝不动。
Linux 桌面被搞坏，最常见的罪魁祸首就是 apt install 装了不该装的包，某个依赖被悄悄升级，连带影响一串系统组件。Flatpak 从根本上切断了这条链路。
必须用 apt 时，只用官方源。 驱动程序、系统工具、桌面环境组件必须走系统包管理器，关键是"从哪装"。官方仓库的包经过兼容性测试，依赖关系是验证过的。
第三方 PPA、外部 deb 源、随机下载的 deb 包，依赖假设可能和你的系统不一致——今天没事，明天一次 apt upgrade 就可能拖入依赖地狱。如果软件不在官方仓库里，先查 Flatpak 有没有。没有再考虑官方提供的 .deb 包，但不要加第三方源。
一句话：Flatpak 管应用，官方源管系统，各管各的，互不干涉。 AppImage 适合临时或便携场景——拷到 U 盘就能跑。Snap 在 Ubuntu 生态中有一定整合度，但社区争议较大，非 Ubuntu 用户优先选 Flatpak。
下次装软件前先问两个问题：这个软件需要碰系统依赖吗？我信任这个来源吗？答案比任何教程都可靠。